102 - Block size increase to 2MB
BIP: 102 source Layer: Consensus (hard fork) Title: Block size increase to 2MB Author: Jeff Garzik Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0102 Status: Rejected Type: Standards Track Created: 2015-06-23 Table of ContentsAbstractMotivationSpecificationBackward compatibilityDiscussionImplementation Abstract Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB. Motivation Continue current economic policy.Exercise hard fork network upgrade. Specification MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.Increase maximum block sigops by similar factor, preserving SIZE/50 formula.Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support. Backward compatibility Fully validating older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off ...
35 - mempool message
BIP: 35 source Layer: Peer Services Title: mempool message Author: Jeff Garzik Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035 Status: Final Type: Standards Track Created: 2012-08-16 Table of ContentsAbstractMotivationSpecificationBackward compatibilityImplementation Abstract Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool. Motivation Several use cases make it desirable to expose a network node's transaction memory pool: SPV clients, wishing to obtain zero-confirmation transactions sent or received.Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart.Remote network diagnostics. Specification The mempool message is defined as an empty message where pchCommand == "mempool"Upon receipt of a "mempool" message, the node will resp...
100 - Dynamic maximum block size by miner vote
BIP: 100 source Layer: Consensus (hard fork) Title: Dynamic maximum block size by miner vote Author: Jeff Garzik Tom Harding Dagur Valberg Johannsson Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 Status: Rejected Type: Standards Track Created: 2015-06-11 License: BSD-2-Clause Table of ContentsAbstractMotivationSpecificationDynamic Maximum Block SizeSignature Hashing Operations LimitsRecommendationsPublication of hardLimitDeploymentBackward compatibilityImplementationsCopyright Abstract Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting. Motivation Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers. Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide. Miners also...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 source Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Rejected Type: Standards Track Created: 2015-08-24 Table of ContentsAbstractMotivationSpecificationProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersRationaleProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersCompatibilityOther solutions consideredDeployment Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Dependi...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Author: Eric Lombrozo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs Abstract This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. Copyright This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. Motivation Bitcoin is a system involving a number of different standards. Some standards are abso...
101 - Increase maximum block size
BIP: 101 source Layer: Consensus (hard fork) Title: Increase maximum block size Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0101 Status: Withdrawn Type: Standards Track Created: 2015-06-22 Table of ContentsAbstractMotivationSpecificationDeploymentTest networkRationaleObjections to this proposalCentralization of full nodesCentralization of mining: costsCentralization of mining: big-block attacksUnspent Transaction Output GrowthLong-term fee incentivesOther solutions consideredOne-time increaseDynamic limit proposalsCompatibilityImplementation Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate. Motivation Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size redu...